The Internet comprises a very heterogeneous set of NATs, in-the-middle components and endpoints that make it hard under certain circumstances for different endpoints (e.g. users or clients) to reach each other.
Real time communications (RTC) is a branch of telecommunications that involves low latency packet routing on networks between two peers. Different examples of RTC technologies are the PSTN and VoIP. On the other hand, the Real-time Transport Protocol (RTP) is a protocol originally designed for two peers to transmit latency sensible content (commonly, audio and video) between them. RTP is used extensively in telephony, video conference protocols and television services, among others.
WebRTC is an API and a set of protocol implementations that enable browsers to stream media real time in a peer to peer fashion. WebRTC can also be compiled and linked independently against other applications to be used outside the browser. The real advantage of WebRTC is that is available in current versions of Chrome™, Firefox™, Opera™ and Microsoft™ and Apple™ are adding support for their respective browsers as well. Users can use WebRTC based applications on their browsers without the need of installing third party plugins or apps.
When two peers want to send media packets to each other using the standard, the first is finding a possible route between the two peers. When deciding how to route packets, peers using WebRTC may use the following protocols: STUN, TURN and ICE.
Next a brief explanation of what each of these protocols is used for, according to the state of the art, is given.
STUN, which stands for Session Traversal Utilities for NAT, is a protocol that provides a mechanism for endpoints with a private IP address and port to find out the IP address and port allocated by a NAT. Additionally, it provides a mechanism to keep the NAT binding alive.
By using STUN, a peer on the Internet might be able to provide other peers on the Internet with a pair of a public IP address and port that other peers can use to send packets to the former one. STUN is a protocol based on sending UDP packets between clients. However, since some firewalls block UDP traffic, or it is not possible for another peer to reach out to the provided IP address of the former peer, a more sophisticated mechanism to cover most scenarios is needed.
TURN, which stands for Traversal Using Relays around NAT, is a protocol that enables two peers in the Internet sending packets to each other even if they cannot reach each other directly. When two peers on the Internet first try to find a route to send packets to each other, they use hole punching techniques to find a direct route, which is a route without any packet relaying. However, if both peers are behind NATs that do not behave in a standard way, peers may consider using a route in which packets are relayed between them.
A TURN server with a public IP address is able to relay packets between peers that are behind NATs in those conditions. In a RTC scenario, it is common to use the RTP protocol on top of UDP. However, since some peers may be behind firewalls that block all UDP traffic, TURN supports besides User Datagram Protocol (UDP), Transmission Control Protocol (TCP) and Transport Layer Security (TLS). These covers most firewalls configurations for outgoing traffic to the Internet.
ICE, which stands for Interactive Connectivity Establishment, is a protocol used for peers to find enough information about their network topology to find a route through which they can talk to each other. Initially, ICE assumes a communication channel between peers through which they can negotiate a session using an offer/answer model, by using a signaling server. Once the peers have negotiated a session they try to find a route between them. In order to do that, there is a stage in which clients gather candidate contact addresses (sets of IP address, port and protocol) that they can send to the other peer, and the other peer can use to try to reach them. In the candidate gathering state, the STUN and TURN protocols are used in order to identify different types of candidates and increase the chances of finding a route between them.
In the context of ICE there is the concept of ICE servers. ICE servers are servers that support the STUN and or TURN protocols. ICE uses the ICE servers to aid the client to gather different kind of ICE candidates in order to find a viable route to the other peer.
The following is a list of the types of candidate contact addresses that can be provided by a peer.                Host candidate: the host candidate is the IP address of the interface bound and the port.        Peer reflexive candidate: when a peer receives a STUN packet with a mapped address that has not already been gathered by the peer, the peer stores it as a peer reflexive candidate        Server reflexive candidate: is a translated address on the public side of the NAT.        Relayed candidate: is the address of a TURN server that can be used to find a relayed route to the other peer.        
The problem statement addressed by present patent application is how to force peers to route packets through a particular server in the Internet in certain scenarios which impose restrictions on data traffic, for instance those networks that require outbound traffic towards the Internet to be routed through certain network nodes. The previous mentioned protocols are used as a basis for the proposed solution, but there is no mechanism defined in the standards and RFCs that allows implementors to force certain routes for peers. There are different scenarios in which it may make sense to force peers to use desired or even necessary routes. A couple of scenarios in which the solution is useful will be listed, but it is all based on the same concept of forcing a route between two peers on the Internet.
Also, another important consideration is that for Peer A and Peer B to start an initial negotiation using the ICE protocol a signaling server needs to be present. The server will provide a means for the two connections to negotiate the session with the respective offer/answer and the candidate exchange. The signaling server can use a protocol based on TCP or UDP depending on the requirements of the application, a protocol such as SIP supports both protocols.
So, the problem is twofold: it has to be considered how Peer A can reach Peer B, but also how Peer A can reach the signaling server for the initial negotiation.
More solutions are therefore needed in order to set up a successful communication between two peers when one of the peers, or both, has data traffic restrictions.